Game physics
Game physics is the way in which the laws of nature are simulated in a computer game. This article focuses on the problems with simulating gravity in a way that is fair for all OpenArena players and independent of their personal hardware and game settings. Frame rate dependent physics Frame rate dependent physics is the way of simulating gravity the OpenArena game engine inherited from its Quake III ancestor. The game server calculates a players position with the PMove() function and it transmits the resulting coordinates to the players game clients represented as integer numbers. If a players coordinates have fractional parts ('decimals behind the dot'), the fractional parts have to be rounded to make them into integer numbers. This makes the moment at which the PMove() function does the rounding have an effect on the result of the rounding: if the rounding is done early the result is rounded down, if the rounding is done late the result is rounded up. Normally the rounding errors will cancel each other out over time because the acceleration is not constant. However there is one notable exception: Gravity. Because gravity is constant rounding errors accumulate over time. Because in frame rate dependent physics the PMove() function is called whenever a client renders a frame, a player can influence the effect of the rounding by tweaking his clients com_maxfps setting. Advantages * Provides that 'good old gravity' feeling for seasoned players. * All old maps are playable as they were meant to (if all players can and do use com_maxfps 125). * No choppy movement as long as the client can hold a steady framerate. Drawbacks * Players with good hardware and the correct game settings experience less gravitational pull than others, giving them an unfair advantage because they can jump higher and thereby farther. Configuration The server can be configured to frame rate dependent physics by setting both pmove_float and pmove_fixed to 0. Fixed frame rate physics Fixed frame rate physics solves the unfairness frame rate dependent physics by calling the PMove() function at the same, fixed time interval for all players, independent of their com_maxfps. This way all players get the same rounding error and thus all can jump the same height. Advantages * Fair physics by emulating the same frame rate dependent physics for all players. * Which frame rate dependent physics will be emulated is configurable (91 fps physics, 125 fps physics, etc.). * All old maps are playable as the were meant to, providing the administrator has set the correct time interval with the pmove_msec cvar (being 8 for 125 fps physics). Drawbacks * Players with bad hardware or wrong game settings don't get to hear a lot of the in-game sounds. * Players with bad hardware or wrong game settings will appear to have the dreaded choppy movement to other players and will experience frequent frame drops themselves, reducing the fun in online games drastically. Configuration The server can be configured to fixed frame rate physics by setting pmove_float to 0, pmove_fixed to 1 and pmove_msec to the desired time interval in milliseconds. The interval is calculated by dividing 1000 by the fps to be emulated, or the other way around: It should be noted that pmove_msec cannot take values below 8 (125 fps) and the upper limit is 66. Accurate physics Accurate physics solves the problems with fair gravity simulation by no longer using an integer number representation of the players positional data but by using floating point numbers instead. Floating point numbers can hold fractional values, making in no longer necessary to do rounding of the players coordinates. Advantages * Fair physics. * No negative side effects like those of fixed frame rate physics. * No choppy movement even if the client framerate are unstable. Drawbacks * Seasoned players can no longer jump as high and far as they are used to without tweaks by the server administrator. * Some jumps and tricks on old maps are no longer possible without tweaks by the server administrator. * Sending floating point numbers over the network instead of integer numbers takes more bandwidth. Configuration The server can be configured to accurate physics by setting pmove_float to 1. The server administrator can influence the jump height by tweaking the g_gravity value and setting up a custom map rotation script (because the game engine resets g_gravity to the default value for that map -usually 800- after each match). In the next release of ''OpenArena a g_gravityModifier cvar will be introduced to solve the problem of having to set g_gravity for each map anew. For those who want to test it, just download and install a recent version of OAX, (like B47) and run a server with it.'' Mods Pmove_float is OpenArena specific and not supported by most old mods. Pmove_fixed is supported by most mods. Vanilla and CPM physics One may find references to "Vanilla" (or "VanillaOA" or "VanillaQ3", thus also "VOA" or "VQ3") physics, opposed to "CPM" (or "CPMA" or "ProMode") physics. The first consists of classic physics and control responses that you can usually find in the standard game. The second consists of modified physics and control responses, to allow even more hardcore tricks, like more mid-air control; it comes from the Challenge ProMode Arena mod for Quake 3, and some more mods, like DeFRaG, implemented similarily modified physics. At the moment, only Vanilla physics is available without the need of using mods. See also * Tweak * Tweak#Tweaking online gaming parameters - Some infos about optimal settings. * Special game options#Game physics - Infos about variables that control in-game gravity, speed and knockback.